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(54) Method for implementing trickplay modes in a data stream recorder 



(57) Stream recording assumes e.g. a settop box to 
be connected to a DVD Streamer. The connection is 
e.g. of IEEE1394 type using interfaces including trans- 
mitting and receiving firmware. Stream Data include 
one or more Stream Objects which each can be stored 
as a Program Stream as described in ISO/IEC 1 381 8-1 , 
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Systems. Each Stream Object contains its own Access 
Unit data. A trickplay mode, e.g. fast forward, is per- 
formed by selecting the desired Access Units which are 
derived from a mapping list with incremental application 
packet arrival times. 
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Description 

[0001] The invention relates to an improved trickplay processing for a data stream recorder, in particular a DVD 
based data stream recorder. 

5 

Background 

[0002] Stream recording assumes an application device, e.g. a set-top box, connected to a DVD Streamer. Both 
devices are connected via e.g. an IEEE1394 (IEC 61883) interface including transmitting and receiving firmware. 
w Stream Data include one or more 'Stream Objects' which each can be stored as a 'Program Stream' as described in 
ISO/IEC 1381B-1. Systems. 

The following abbreviations are used in the description: APAT: application packet arrival time, ATS: application times- 
tamp. AU: access unit, AUD: AU data, AUELL: access unit end location list, AUEM: access unit end map, AULL: access 
unit location list, AUSLL: access unit start location list, AUSM: access unit start map, DTS: decoding timestamp, DVD: 
is digital versatile disc, DVD RTRW: DVD realtime rewritable. DVD VR: DVD video recording, IAPAT: incremental applica- 
tion packet arrival time, MAPL: mapping list, LB: logical block. PAT: packet arrival time, PES: packetised elementary 
stream, PTS: presentation timestamp, SCR: system clock reference, SOB: stream object, STB: set top box, S_PCK: 
stream pack, TOG: table of content. 

[0003] A SOB can be terminated by a program_end_code. The value of the SCR field in the first pack of each SOB 
20 may be non-zero. A SOB contains the Stream Data packed into a sequence of Stream Packs. Stream data can be 
organised as one elementary stream and are carried in PES packets with a streamjd. 

[0004] In Stream recording, the application performs its own padding so that the pack length adjustment methods 
of DVD-ROM Video or RTRW need not to be used. In Stream recording it is safe to assume, that the Stream packets 
will always have the necessary length. 

25 

Invention 

[0005] The invention allows to realise Access Units. The resulting Alls have a resolution range from 2 SOBUs up 
to 'application packet' exact. The precision depends on the used DVD Streamer, i.e. whether the DVD Streamer knows 
30 the application and e.g. how much RAM memory is available. Therefore the precision depends on the design of the 
manufacturer. Each SOB contains its own AU data. This AUD consists of a general information, one or two coarse lists 
and one or two fine lists. 

The coarse list is called the Access Unit Start Map AUSM. The AUSM consists of N flags (N is the number of SOBUs 
of this SOB). Each flag belongs to one SOBU. The flag indicates that: 

35 

an AU points into the corresponding SOBU or into the next SOBU; 
no corresponding AU exists for that flag. 

[0006] A fine list is called the Access Unit Location List AULL and contains the exact locations of the application 
40 packets of all AUs. For each AU indicating AUSM/AUEM flag there exists one location information inside AULL 
Two kinds of AULLs exist: 

The part inside the AULL containing the start location is called the Access Unit Start Location List AUSLL. The part 
inside the AULL containing the end location is called the Access Unit End Location List AUELL. 
The complete AU information of an SOB consists of either 

45 

the sector & application packet location of the start of the AU and 

the sector & application packet location of the end of the data which starts at the AU (e.g. the end of the l-frame) 
and 

• the PTS of the AU 
so or 

• the start APAT of the AU 

the end APAT of the AU (e.g. the end of the l-frame) and 

• the PTS of the AU 
or 

55 • the start ATS of the AU 

the Access Unit End Map AUEM of the AU (for the end ATS of the AUs) 

• the end ATS of the AU. based on AUEM, not AUSM, and 

• the PTS of the AU 
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[0007] It is possible to have a subset only of the above values, e.g. AUSM or AUSM and AUEM. 

[0008] It is one object of the invention to disclose a method and a recorder for implementing trickplay modes in a 

data stream recorder. This object is achieved by the features disclosed in claim 1. 

[0009] A trickplay mode, e.g. fast forward, is performed by selecting the desired AUs, e.g. each second AU, via 
5 AUSM/AUEM. The generation of AUSM, AUEM, AUSLL and AUELL during SOB recording is optional, i.e. is a matter of 
the manufacturer. The use of AUSM, AUSM, AUSLL and AUELL for trickplay modes is also optional. However, it is man- 
datory to update AUSM. AUEM and AULL in the case of editing. Fig. 3 to 5 show three examples. 
[001 0] The DVD Streamer specification defines the syntax of the AUs, not the generation or use of the AUs. How- 
ever, here are some examples for how to generate AUSM/AUEM and AULL: 

w 

A) The application device sends after transmission of the stream special data which contain a list of AU as APATs, 
i.e. each APAT of the list is the APAT of one of the just recorded application packets. The streamer must assign each 
APAT to the corresponding application packet: 

7 5 A high end streamer generates a special list during stream recording. This list contains the APAT values of 

each recorded application packet and the corresponding location in the stream, e.g. sector No. and application 
packet No. . When the application sends the AU list as a list of APATs, the streamer is able to generate all lists: 
AUSM/AUEM (SOBU accurate) and AULL. 

A standard streamer has not enough memory to generate a list with APATs and application packet location 
20 information inside the local RAM. Therefore, in this case the streamer will generate only the AUSM (2 SOBU 

accurate), but not the AUEM and AULL. After that, a high end streamer could generate therefrom the accurate 
AULL and AUEM (SOBU accurate) and could refine AUSM SOBU accurate, e.g. during an idle mode of this 
high end streamer. 

25 • B) The streamer contains dedicated hardware to parse the incoming stream, i.e. the application is known by the 
streamer. This parser recognises automatically Access Units like l-pictures. With such additional hardware 
AUSM/AUEM (SOBU accurate) and AULL can be easily generated during stream recording. 
• C) The application uses special digital interface commands to mark an application packet as AU during transmis- 
sion of the stream to the streamer. Then the streamer is able to generate AUSM/AUEM and AULL in parallel during 

30 stream recording if the digital interface is defined accordingly. 

D) The application knows nothing about the streamer. In this case AUs will not be generated. After that a high end 
streamer can generate the missing AU?M/AU EM (SOBU accurate) and AULL, e.g. during idle mode of the 
streamer. 

35 [001 1 ] Trickplay modes can be applied with or without end of AU information. 

Without end of AU information: 

[0012] The trickplay mode. e.g. fast forward, is performed by searching for the desired AUs, e.g. each second AU. 

40 inside the AUSM. If existing, with AULL the exact location of the first application packet of the AU is known. Without 
AULL, the streamer assumes that the AU is located anywhere in the SOBU indicated by AUSM or in the following 
SOBU. The streamer jumps to this position and starts the transmission of the application packets to the application with 
the first application packet of this SOBU. The streamer stops the transmission after having transmitted a fixed amount 
of data, e.g. 1 .8 Mbit or until the next AU, and jumps to the next desired AU. If the streamer knows the application it can 

45 parse the stream during transmission of the AU and will stop the transmission when the end of the AU is reached, e.g. 
the end of an l-picture. 

If the stream contains AU flags (AU start / AU end), then the transmission of the AU can also be performed application 
packet accurate. 

so With end of AU information: 

[0013] The only difference to the first alternative is that, if the AULL exists, the transmission of an AU to the appli- 
cation device stops with the transmission of the last application packet of the AU. 

[0014] Bitstream data (start and end marks) and navigation data (for AUSM, AUEM, AULL) are stored on the disc 
55 separately, i.e. in different files. 

[001 5] In principle, the invention is suited for implementing trickplay modes in a bitstream recorder, wherein the bit- 
stream is organised in stream objects and access to the bitstream is performed using access units and access unit 
information is attached to the stream objects of the bitstream and to navigation data to be recorded, and wherein said 
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access unit information includes an access unit start map, and optionally an access unit end map. which are used in 
the trickplay modes together with the navigation data for access to the bitstream. 

[0016] Advantageous additional embodiments of the invention are disclosed in the respective dependent claim. 
5 Drawings 

[001 7] Embodiments of the invention are described with reference to the accompanying drawings, which show in: 

Fig. 1 simplified overall system for DVD Stream Recording; 

w Fig. 2 basic directory and file structure; 

Fig. 3 access to application packet via AUSM and AULL; 

Fig. 4 access to application packet via AUSM, but without AULL; 

Fig. 5 access to application packet whereby AULL also contains end of AU information; 

Fig. 6 table showing the maximum possible Access Unit support which is storable by a specific configuration; 

15 Fig. 7 structure of a Stream Object Information; 

Fig. 8 structure of the AUD_FLAG byte; 

Fig. 9 structure of the Access Unit Data; 

Fig. 10 example of an AUSM and its corresponding SOBUs; 

Fig. 1 1 example of AUSM, AUSLL, AUEM, AUELL and the related data access mechanism. 



20 



Exemplary embodiments 



[001 8] Fig. 1 shows a simplified block diagram of a settop box AD and a Stream recorder device STRD. AD inter- 
acts via an interface IF. e.g. an IEEE1394 interface, with STRD. AD sends its data via output buffering & timestamping 

25 handling means BTHOAD to IF and receives from IF data via input buffering & timestamping handling means BTHIAfr 
A streamer STR within STRD sends its data via output buffering & timestamping handling means BTHO to IF and 
receives from IF data via input buffering & timestamping handling means BTHI. 
Instead of an IEEE1 394 connection any other network like the Ethernet or the Internet can be used. 
Instead of a settop box any other data stream source can be used, e.g. a DVD player or a PC or Internet receiver. In 

30 that case ANT and TU is replaced by e.g. an optical disc and a pickup. 

[001 9] The DVD Stream Recording system is designed to use rewritable DVD discs for recording existing digital bit- 
streams, editing them and playing them back as bitstreams. This system is designed to satisfy the following require- 
ments: 

35 • A timing mechanism, i.e. a time stamp is added to every broadcast packet to enable proper packet delivery during 
playback. 

To enlarge the fields of applications, non-real-time recording should be possible. However, jn this case the STB has 
to generate the timestamp information. 

Data allocation strategy and a file system to support real-time stream recording. 
4o • Many digital services require Service Information which normally is embedded in the real-time stream. To support 
a STB fed by data from a DVD player, the DVD should provide additional space, which can be used by the STB to 
duplicate part of the service information and to add additional TOC information. 

Copy Protection must be supported. In addition, any scrambling performed by the service provider or the STB must 
be kept unchanged. 

45 

[0020] User requirements can be grouped into requirements for recording, requirements for playback, and require- 
ments for editing: 

Real-time Recording 

50 

[0021] The system is designed to enable real-time recording of digital streams. It allows the user to concatenate 
recordings, even if those recordings consist of different stream formats. If recordings are concatenated, a seamless or 
close-to-seamless playback feature can be achieved, but is not required. 

55 Navigation Support 

[0022] To support navigation two pieces of information (lists) are generated during recording: 



BNSOOCID: <EP 1 039466 A2 I > 



4 




EP 1 039 468 A2 

1) An 'original* version of a play list. This list contains quite low level information, e.g. time map or (broadcast) 
packet order of the recording. This list is accessible by the STB and the content is understood by the DVD streamer 
as well as by the STB. In its original version the playlist enables the playback of a complete recording. The playlist 
may be accessed and extended after recording by the STB to allow more sophisticated playback sequences. 
5 2) The second piece of information, a mapping list, is generated to support the stream recorder to retrieve packet 

stream chunks (cells), that are described in terms of the application domain, e.g. "broadcast packets' or 'time'. This 
list is owned and understood by the DVD streamer only. 

Content Description 

10 

[0023] The system can reserve space which can be used by the STB to store high-level TOC and Service Informa- 
tion. This information is provided for the user to navigate through the content stored on disc and may contain sophisti- 
cated EPG information. The content needs not to be understood by the stream recorder. However a common subset of 
the TOC information, e.g. based on a character string, may be useful to be shared between STB and DVD, in order to 
is enable the stream recorder to provide a basic menu by itself. 

Player menus for access unit selection 

[0024] Playback of individual recording and playing all recordings sequentially is possible via a play list. 
20 The STB can generate a sophisticated menu based on the TOC information stored on the disc. A simple menu is gen- 
erated by the streamer itself, e.g. via some 'character* information which is shared by STB and DVD. 
The DVD streamer creates the 'original version' of the play list. It can allow extensions and modifications of the play list 
by the STB for more sophisticated playback features. 

The DVD streamer is not responsible for the content of those sophisticated playlist(s). 
25 The system supports the deletion of single recordings on user's request. Preferably the system allows this feature under 
the control of the STB. 
The system may support insert editing. 

[0025] Concerning the directory and file structure, the organisation of Stream Data and Navigation Data of DVDi 
Stream Recording is done in a specific way such as to take into account the following: 

30 

Any DVD Streamer device has certain requirements to store its own housekeeping data or Streamer-specific nav- 
igation data on the disc. These data are solely for helping the retrieval of recorded data; they need not be under?: 
stood or even be visible to any outside application device AD. 

Any DVD Streamer device needs to communicate with the application device AD it is connected to. This communi- 
35 cation is as universal as possible so that the maximum possible range of applications can be connected to the 
Streamer. The Navigation Data to support such communication are called Common navigation data and must be 
understandable by the Streamer as well as by the application device. 

The Streamer device offers to the connected application device AD a means for storing its own private data of any 
desired kind. The Streamer needs not to understand any of the content, internal structure, or meaning of this appli- 
40 cation -specific navigation data. 

[0026] A possible directory and file structure is described in connection with Fig. 2. Under the root directory, the files 
storing the disc content are placed under the STRREC directory. Under the STRREC directory the following files are 
created: 

45 

- COMMON. IFO 

Basic information to describe the stream content. Needs to be understood by the Application Device as well as 
the Streamer. 

- STREAMER. IFO 

so Private housekeeping information specific to the Streamer Device. Needs not to be understood by the Applica- 

tion Device. 

- APPLICATIFO 

Application Private Data, i.e. information that is specific to the Application(s) connected to the Streamer. Needs 
not to be understood by the Streamer. 
55 - REALTIME. SOB 

Recorded real-time stream data proper. 
Note that except for the files described above, the STRREC directory shall not contain any other files or directories. 
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[0027] The DVD Streamer Format Draft, version 0.3, realises trick play support by the Entry Point Data of Section 
2.2.3.3.3. According to the invention, some of these features have been revised in order to allow improved trickplay 
modes. The invention takes the following into account: 

5 • The sector based addressing mechanism has been deleted. 

The wordlength of the time based addressing information has been changed from a 6 byte time value of the APAT 
■type to a 4 byte time value of the ATS type. As a side effect, a second bit flag array AUEM has been introduced in 
parallel to the already existing AUSM. In this new format, the time based address information is not only more com- 
pact, but also more directly usable. 

to • All 'Entry Point XXX' terms have been renamed to 'Access Unit XXX' in order to avoid confusion with the user con- 
trolled Entry Points in Cell Information, which still exist. 

[0028] The invention can also be used without value AULL. As shown in Fig. 7 the Stream Object Information SOBI 
includes the Stream Object Information General Information SOBI_GI, the Mapping List MAPL and the Access Unit 
is Data AUD, if any. The mapping list includes incremental application packet arrival times and is described in more detail 
in EP 98250387.2 of the applicant. 
[0029] SOBIJ3I may have the following format: 





Contents 


Number of Bytes 


(1)SOB_TY 


SOB Type 


1 


(2) SOB_REC_TM 


SOB Recording Time 


5 


(3) SOB_STI_N 


SOB Stream Information Number 


1 


(4) AUD_FLAGS 


Access Unit Data Flags 


1 


(5) SOB_S_APAT 


SOB Start APAT 


6 


(6) SOB_E_APAT 


SOB End APAT 


6 


(7) SOB_S_SOBU 


first SOBU of this SOB 


4 


(8) MAPL_ENT_Ns 


number of Mapping List entries 


4 




Total 


28 
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w 



15 



20 



25 



30 



35 



AO 



45 



50 



(1) SOBJTY 

Describes the Stream Object Type, containing bits for Tempo- 
ral Erase state (TBD) and for Copy Generation Management 
System (TBD) . 

(2) SOB_REC_TM 

Describes the recording time of the associated Stream Object 
in DVD Stream Recording' s Date and Time Describing Format 
defined above. 

(3) SOB_STI_N 

Describes the index of the BOB_STI which is valid for this 
S:ream Object. 

(4) AUD_ FLAGS 

Indicates whether and what kind of Access Unit Data exist 
for this SOB. If Access Unit Data exist, then AUD_FLAGS also 
describes several properties of the Access Unit Data. The 
Access Unit Data itself is described below and includes the 
number of Entry Points and the tables AUSM, AUSLL, AUEM, 
AUELL and PTSLL. The content of AUD_ FLAGS is depicted in 
Fig. 8. 

RTAU_FLG 0: no AU flags exist inside the RT Data of this 
SOB 

1: AU flags may exist inside the RT Data of 

this SOB. This state is even allowed, when 
no further Access Unit Data exist fcr this 
SOB, i.e. if AUD_FLG = Ob . 
AUD_FLG 0: no Access Unit Data exist for this SOB. The 
bits b5, b4, b3 and b2 of EP_ FLAGS shall be 
set to 0. 

i: Some Access Unit Data (as further specified 
by the subsequent flags) exist for this SCB, 
behind the MAPL. 
AUSLL_FLG 0: no AUSLL of this. SOB exists 

1: AUSLL of this SOB exists 
AUEM_FLG 0: no AUEM of this SOB exists. AUELL_FLG must 
then also be set to 0b. 
I: AUEM of this SCB exists 
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w 



15 



20 



25 



AUELL_FLG 0: no ATJELL of rhis SOB exists 

1: ALJSLL of this SOB exists- Is only allowed if 
AUEM_FLG = lb. 
PTSL_FLG 0: no PTSL of this SOB exists 

1: PTSL of this SOB exists 

(5) SOB_S_APAT 

Describes the start Application Packet Arrival Time APAT of 
the Stream Object, i.e. the packet arrival time of the first 
packet belonging to the SOB. SOB_S_APAT is described in DVD 
Stream Recording's PAT Describing Format defined below; 
PATs are divided into two parts, namely a base part and an 
extension part. The base part PATJoase (bits 9 to 47) holds 
the so-called 90kHz unit value, and the extension part 
PAT_exten (bits 0 to 8) holds the less significant value 
measured in 27MHz: 

PAT in seconds = PAT_base/ 90kHz + PAT_exten/27MHz 
For a unique representation of times, PAT_exten must be in 
rhe range of 0 < PAT__exten < 300. Together, PAT__base and 
PAT exten cover a range of more than 1696 hours. 



35 (6) SOB_E_APAT 

Describes the end Application Packet Arrival Time of the 
Stream Object, i.e. the packet arrival time of the last 
packet belonging to the SOB, in DVD Stream Recording's PAT 
Describing Format. 

(7) SOB_S_SOBU 

Describes the number of the start. Stream Object Unit, i.e. 
the Stream Object Unit containing the first Application 
Packet of the Stream Object. 

(8) MAPL_ENT_Ns 

Describes the number of Mapping List entries to follow after 
SOBI GI. 



30 



40 



45 



SO 
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[0030] As shown in Fig. 9, the Access Unit Data AUD, if any, include the Access Unit General Information AU_GI, 
and may also include the Access Unit Start Location List AUSLL, the Access Unit End Map AUEM, the Access Unit End 
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Location List AUELL and/or the Presentation Time Stamp List PTSL Which of these parts exist is indicated by 
AUD_FLAGS of SOBI_Gi. see above. 

[0031 ] AU J31 only exists if AUD — FLAGS of SOBIJ3I indicates that Access Unit Data exist. 

5 





Contents 


Number of Bytes 


(1) AUJvIs 


number of Access Units 


4 


(2) AUSM 


Access Unit Start Map (MAPL_ENT_Ns entries) 


(MAPL_ENT_Ns+7) div 8 




Total 


4+(MAPL_ENT_Ns+7) div 8 



(1)AU_Ns 

Describes the number of Access Units described for this SOB. At the same time, AU_Ns describes the 
7 5 number of locations where AUSM indicates the existence of an Access Unit- 

es) AUSM 

The Access Unit Start Map indicates which of the SOBUs of this SOB contain Access Units. For each 
SOBU of the SOB, exactly one AUSM entry exists. Therefore the AUSM consists of MAPL_ENT_Ns 
entries. Each AUSM entry indicates an accessible Access Unit somewhere within the corresponding 
SOBU or within the subsequent SOBU. Exactly AU_Ns Access Units are indicated by the AUSM, equiv- 
20 alent to exactly AU__Ns bits of AUSM being equal to M '. 



[0032] AUSM shall be byte aligned. If the concatenated AUSM entries consist of a number of bits which are not an 
integer multiple of '8', then the remaining LSBs of the last byte of the AUSM shall be the necessary additional padding 
25 bits. These alignment bits shall be set to '0'. 

[0033] Fig. 10 shows an example of an AUSM and its corresponding SOBUs. With this kind of Access Unit Data, 
no more than one addressable Access Unit can be described per each SOBU of the SOB. 

[0034] Concerning the Access Unit Start Location List AUSLL, Access Unit End Map AUEM and Access Unit End 
Location List AUELL, AUSLL is a list of location information to find the application packet where the bitstream segments 

30 of the Access Units start. Therefore, if AUSLL exists, each Access Unit as marked in AUSM has exactly one AUSLL 
entry associated to it. AUEM, if it exists, is a bit array of the same length as AUSM. The bits in AUEM indicate which of 
the SOBUs contain the end of the bitstream segment associated with the Access units of the SOB. The number of bits 
set in AUEM must be equal to the number of bits set in AUSM. AUELL, if it exists, is a list of location information to find 
the exact application packet where the bitstream segments of the Access Units stop. Therefore, if AUELL exists, each 

35 Access Unit as marked in AUEM has exactly one AUELL entry associated to it. Each application packet, indicated by 
the AUELL entries, is the last application packet belonging to the Access Unit. 
The entries of AUSLL and AUELL are in ascending order, i.e. 

• the first AUSLL/ AUELL entry is associated to the SOBU number, where AUSM/ AUEM - read from the left to the right 
40 - has a bit set to ' 1 ' for the first time 

• the second AUSLL/ AUELL entry is associated to the SOBU number, where AUSM/AUEM - read from the left to the 
right - has a bit set to '1 ■ for the second time 

and so on. 

45 [0035] The entries of AUSLL and AUELL are time based, i.e. their entries are defined as 





Contents 


Number of Bytes 


(1) AU_ATS 


ATS of the designated Application Packet 


4 




Total 


4 
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(1)AU_ATS 

AU_ATS describes the Application Time Stamp of an application packet inside the 
SOBU associated with this entry. When data readout has begun at the start of the 
SOBU, these AU_ATS are identified by comparing them with the individual ATS of the 
5 Application Packets inside the bitstream data. Fig. 1 1 shows an example of AUSM, 

AUSLL, AUEM, AUELL and the related data access mechanism. 

[0036] The Presentation Time Stamp List PTSL is the list of the Presentation Time Stamps of all the Access Units 
of the SOB, i.e. if PTSL exists, each Access Unit has exactly one corresponding PTSL entry, and PTSL then has AU_Ns 
io entries. The entries of PTSL are in ascending order, i.e. 

the first PTSL entry is associated to the Access Unit occurring first inside AUSM 

the second PTSL entry is associated to the Access Unit occurring second inside AUSM 

and so on. 

15 

Each PTSL entry is defined as 
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25 



30 





Contents 


Number of Bytes 


(1)PTS 


PTS of the corresponding Access Unit 


4 




Total 


4 



[0037] The entries of the table depicted in Fig. 6 show the maximum possible Access Unit support which is storable 
by the described configuration. This is the performable support just after an SOB recording. If an entry consists of two 
states, separated by a slash, that entry describes the following: 

left side of the slash: the status just after the recording of a SOB 
• right side of the slash: the status after a second off-line session, e.g. an hour at night. 

[0038] Some explanations for using this Access Unit Support table: 



35 SOBU desired application packet is in the indicated SOBU; 

2 SOBU desired application packet is in the indicated SOBU or in the following SOBU; 

APAT complete APAT of the desired application packet. The streamer is not able to calculate directly the sector and 
application packet number from the APAT, i.e. an access to the application must be performed via the MAPL; 
packet exact and direct application packet location. The location is given by a sector number and the application 
40 packet number inside this sector. 

[0039] Different DVD Streamer types are listed horizontally: 

simple Streamer, less memory: A streamer without any dedicated knowledge about the application STB. The 
45 streamer has just enough RAM to store a coarse list which indicates the SOBUs containing an AU. 

Streamer is simple but additional memory is available: Similar to the previous streamer. The only different is 

a) just enough memory for AUs: the streamer has additional RAM to store the complete AU information (a 
coarse list + AU start location + AU end location + PTS); 
so b) more memory: the streamer has additional RAM to store the complete AU information (coarse list + AU start 

location + AU end location + PTS) and the exact packet location + ATS inside the RAM for each incoming appli- 
cation packet during recording. 



55 



Streamer with dedicated hardware to parse streams, less memory: 

the streamer has just enough RAM to store a list which indicates the SOBUs containing an AU. The streamer 
knows the application, i.e. the streamer is able to find the AUs (start, end and PTS) during recording and play- 
back due to the implemented stream parser. 
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Streamer with dedicated hardware to parse streams, additional memory is available: 

this streamer has additional RAM to store the complete AU information (coarse list + AU start location + AU 
end location + PTS). The streamer knows the application, i.e. the streamer is able to find the AUs (start, end 
5 and PTS) during recording and playback due to the implemented stream parser. 

[0040] Various application device types are listed vertically: 

simple STB: 

w the application is not aware of the existence of the streamer. 
STB sends AU list after recording: 

the application knows that a streamer records the sent application packets. After recording of a take (SOB) the 
application sends a list of AU information (AU start ATS + AU end ATS + PTS) to the streamer. 
STB sends AUs during recording: 
is the application knows that a streamer records the sent application packets. During recording of a take (SOB) the 
application sends in parallel, e.g. via an isochronous channel, AU information (AU start ATS + AU end ATS + PTS) 
to the streamer. 

[0041] The navigation data related to one Access Unit includes four items of information: 

20 

coarse: 

coarse list. The list describes the SOBUs which. have an AU. 
fine: 

fine list. This list describes the unambiguous location of the AU either as APAT or as sector number + application 
25 number inside this sector, 
last: 

fine list of the last application packet which belongs to this AU. It's also a list of the unambiguous location of each 
AU either as APAT or as sector number + application number inside this sector. 
• PTS: 

30 list of PTSs. Each AU has exact one PTS. 
stream: 

means AU marks inside the stream. If. 'yes* the stream contains additional information for the streamer to detect 
such application packets which contain an AU start or an AU end. 

35 Claims 

1. Method for implementing trickplay modes in a bitstream recorder (STRD), and corresponding recorder (STRD), 
wherein the bitstream is organised in stream objects (SOB) and access to the bitstream is performed using access 
units (AU) and access unit information is attached to the stream objects of the bitstream and to navigation data 

40 recorded, or to be recorded, and wherein said access unit information includes an access unit start map (AUSM), 
and optionally an access unit end map (AUEM), which are used in the trickplay modes together with the navigation 
data for access to the bitstream. 

2. Bitstream recorder (STRD) implementing trickplay modes, wherein the bitstream is organised in stream objects 
45 (SOB) and access to the bitstream is performed using access units (AU) and access unit information is attached to 

the stream objects of the bitstream and to navigation data recorded, or to be recorded, and wherein said access 
unit information includes an access unit start map (AUSM), and optionally an access unit end map (AUEM), which 
are used in the trickplay modes together with the navigation data for access to the bitstream. 

so 3. Method or recorder according to claim 1 or 2, wherein said trickplay modes include fast forward, fast reverse, slow 
motion, single picture step and/or still picture. 

4. Method or recorder according to any of claims 1 to 3, wherein said bitstream contains access unit start and access 
unit end marks which indicate the start or the end of an access unit, respectively. 

55 

5. Method or recorder according to any of claims 1 to 4, wherein said access unit information includes an access unit 
start map (AUSM) and optional one or more of access unit end map (AUEM), access unit start location list (AUSLL) 
and access unit end location list (AUELL). 
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6. Method or recorder.according to claim 5 wherein, if the access unit end map (AUEM) exists, for each access unit 
start map (AUSM) entry an access unit end map (AUEM) entry is provided. 

Method or recorder according to claim 5 or 6, wherein the index of each access unit end map entry is equal to or 
greater than the entry index of its corresponding access unit start map entry and is less than the index of the imme- 
diately following access unit start map entry if any following access unit start map entry exists. 
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